Украинская баннерная сеть
  • Как построить в запросе "Дерево"?
  • Как избавиться от ошибки "multiple rows in singleton select"?
  • Почему после выдачи Commit или RollBack при открытых таблицах или запросах они перечитываются полностью?
  • Что такое SHADOW в InterBase?
  • Поддерживает-ли Interbase поля типа autoincrement?
  • Как определить реальный размер поля типа BLOB, которое сохранено в таблице?
  • Конвертация типов полей через COMPUTED BY.
  • Как правильно получить список таблиц, просмотров, функций и процедур в БД?
  • Как ускорить выполнение множественных записей?
  • Как выбрать размер страницы БД?
  • Как определить дисковое пространство, необходимое для хранения БД?
  • Можно-ли использовать имя таблицы как параметр хранимой процедуры?
  • Как оптимизировать запросы?
  • Можно-ли в запросах делать поиск по BLOB?
  • Есть-ли способ восстановить несохраненные (uncommitted) изменения БД, например в случае отключения питания?
  • Я создал БД с правами пользователей в Local IB. После переноса этой БД на InterBase for NT все пользователи куда-то "пропали". В чем дело?
  • Что такое ISC4.GDB? Для чего нужна эта БД?
  • Можно-ли создать пользователя БД при помощи SQL-команды?
  • Почему таблица или Select показывается в Grid быстро, а перемещение в конец таблицы происходит долго?
  • Как получить значение генератора?
  • Как получить список пользователей Interbase?
  • Как программно сменить пароль входа на Interbase?
  • InterBase и использование Кирилицы.
  • Получение значения поля типа Memo без использования объекта TDBMemo.

    Как построить в запросе "Дерево"?

    Много прекрасных предложений по этому поводу проходилов Интернете. Но на мой взгляд, самым интересным является решение Киевского программиста Правоверова Олега -
    1. Для примера, предлагается создать таблицу следующей конструкции:
    CREATE TABLE TABLEBOOK(
    POLE_ID INTEGER,
    POLE_NAME VARCHAR(50),
    POLE_PARENT INTEGER)
    Важно чтобы дочерние записи в этой таблице своим полем "POLE_PARENT" соответствовали родительскому полю "POLE_ID".
    2. Для построения "Дерева" построим следующую рекурсивную хранимую процедуру:
    CREATE PROCEDURE TABLE_BOOK (
    PARENT_ID INTEGER,
    I_LEVELS INTEGER,
    ) RETURNS (
    POLE_ID INTEGER,
    POLE_NAME VARCHAR(50),
    POLE_PARENT INTEGER,
    LEVELS INTEGER
    ) AS
    DECLARE VARIABLE I INTEGER;
    DECLARE VARIABLE C INTEGER;
    BEGIN
    FOR
    SELECT
    POLE_ID,
    POLE_NAME,
    POLE_PARENT
    FROM
    TABLEBOOK
    WHERE
    (POLE_ID > :PARENT_ID) AND
    (POLE_PARENT = : PARENT_ID)
    INTO :POLE_ID, :POLE_NAME, :POLE_PARENT
    DO
    BEGIN
    SELECT
    COUNT(*)
    FROM
    TABLEBOOK
    WHERE
    (POLE_PARENT = :POLE_ID)
    INTO :C;
    BEGIN
    LEVELS = :I_LEVELS + 1;
    SUSPEND;
    END
    IF (:C > 0) THEN
    BEGIN
    FOR
    SELECT
    POLE_ID,
    POLE_NAME,
    POLE_PARENT,
    LEVELS
    FROM
    TABLE_BOOK(:POLE_ID, :LEVELS)
    INTO :POLE_ID, :POLE_NAME, :POLE_PARENT, :LEVELS
    DO
    BEGIN
    SUSPEND;
    END
    END
    END
    END
    Теперь достаточно послать таблице TABLEBOOK запрос:
    SELECT * FROM TABLE_BOOK(0, 0)
    а дальше, как говорится дело, техники - поместить упорядоченное содержимое, на пример в TTreeView.

    Как избавиться от ошибки "multiple rows in singleton select"?

    Данная ошибка может происходить в Вашем триггере или хранимой процедуре. Обычный SELECT внутри триггера или процедуры должен возвращать одну строку (row), т.к. при двух и более строках InterBase не знает куда поместить значения полей этих строк. Если ваш SELECT возвращает несколько записей, то нужно пользоваться конструкцией FOR SELECT ... INTO ... DO ... которая производит обработку возвращаемого набора записей в цикле. Если-же Вы уверены, что Ваш SELECT должен вернуть только одну запись, а ошибка все-таки возникает, то давайте рассмотрим следующую ситуацию:
    Существуют таблицы ORDERS (заказы) и CLIENTS (клиенты). Обе эти таблицы имеют поле связи CLIENT_ID INTEGER. Для того чтобы вытащить информацию о клиенте используется запрос
    SELECT
    CLIENT_ID,
    CLIENT_NAME
    FROM CLIENTS
    WHERE CLIENT_ID = ?
    где ? - либо значение либо переменная.
    Теперь представим себе, что этот запрос должен выполняться в триггере при вставке записи в таблицу ORDERS
    CREATE TRIGGER TI_ORDERS FOR ORDERS
    ACTIVE AFTER INSERT POSITION 0
    AS
    DECLARE VARIABLE CID INTEGER;
    DECLARE VARIABLE CNAME CHAR(30);
    BEGIN
    SELECT
    C.CLIENT_ID,
    C.CLIENT_NAME
    FROM CLIENTS C
    WHERE C.CLIENT_ID = CLIENT_ID
    INTO :CID, :CNAME;
    ...
    Итак, поскольку в запросе использован псевдоним C (FROM CLIENTS C), то якобы существует гарантия что в предложении WHERE будут сравниваться поле C.CLIENT_ID из таблицы CLIENTS и поле CLIENT_ID из таблицы ORDERS (в триггере доступны имена полей собственной таблицы). Hа самом деле даже использование псевдонимов не дает гарантии что переменные будут разичаться, и получается что в предложении WHERE сравнивается само с собой поле таблицы CLIENTS.CLIENT_ID, и в запросе возвращается ВСЯCLIENTS. Вот почему возникает вышеупомянутое сообщение об ошибке. Избавиться от него можно несколькими путями:
    1. Использовать разные имена полей для связи между CLIENTS и ORDERS. например OCLIENT_ID и CCLIENT_ID.
    2. Использовать уточнитель new.CLIENT_ID, несмотря на то что в документации указано что для триггеров последействия (AFTER) он не имеет смысла.
    SELECT
    C.CLIENT_ID,
    C.CLIENT_NAME
    FROM CLIENTS C
    WHERE C.CLIENT_ID = new.CLIENT_ID
    ...
    3. Перед запросом поместить CLIENT_ID в локальную переменную, и в запросе использовать сравнение не с полем, а с этой локальной переменной.
    CID = CLIENT_ID;
    SELECT
    C.CLIENT_ID,
    C.CLIENT_NAME
    FROM CLIENTS C
    WHERE C.CLIENT_ID = CID
    ...

    Почему после выдачи Commit или RollBack при открытых таблицах или запросах они перечитываются полностью?

    Hачнем с того, что такое перечитывание происходит не всегда. Если вы открываете TTable или TQuery в контексте какой-либо транзакции, то содержимое этих источников данных определяется уровнем изоляции транзакции (ReadCommitted или RepeatableRead). Если при открытых источниках данных завершить транзакцию подтверждением или откатом, то контекст транзакции сменится - вступит в действие т.н. неявная транзакция, которая стартует после соединения с БД. В результате данные, прочитанные до смены контекста могут стать неактуальными, поэтому BDE фактически переоткрывает курсоры. А поскольку неизвестно, на какой строке выборки завершилась явная транзакция, считываются все записи (fetch до конца таблицы). Следует избегать таких ситуаций, и по крайней мере достаточно большие выборки закрывать перед завершением явной транзакции.
    Более подробную информацию о поведении BDE при commit/rollback вы сможете получить в BDE32.HLP, пункт DbiEndTran.

    Что такое SHADOW в InterBase?

    Shadow - это программное "зеркалирование" БД. Все операции записи, производимые над каким-либо файлом GDB параллельно производятся и над соответствующим файлом SHADOW. При сбое GDB вы можете остановить работу пользователей и просто скопировать Shadow на место оригинальной БД (GDB), после чего продолжить работу. Hеобходимо учитывать, что поддержка Shadow замедляет операции изменения БД. Желательно чтобы Shadow располагалась на другом винчестере, и еще лучше если винчестеры с GDB и Shadow будут иметь разные контроллеры - в этом случае запись будет распараллеливаться.
    В ДемоЦентре проводились элементарные тесты на Local InterBase 4.1 (из комплекта Delphi 2.0) под Windows95. Тест представлял собой добавление 10000 (десять тысяч) записей в пустую БД, каждые 1000 записей обрамлялись StartTransaction-Commit. Использовался HDD с контроллером IDE: (одна запись = ~100 байт + BLOB-поле 512К) усредненное время
    без Shadow 4мин 40сек
    с Shadow на том-же винчестере 6мин 00сек
    с Shadow на другом винчестере 4мин 50сек
    Разумеется, при интенсивной многопользовательской работе и достаточно большой базе данных теоретически должны ожидаться следующие результаты коэффициент замедления
    без Shadow 1
    с Shadow на том-же винчестере 1.6 (минимум в полтора раза)
    с Shadow на другом винчестере ~1 (почти без замедления)
    Кроме того, очень сильное влияние на быстродействие InterBase оказывает параметр Forced Writes - немедленное сохранение изменений страниц. Вы можете включить или выключить этот параметр для конкретной БД на ходу при помощи Server Manager. При выключенном Forced Writes работа с БД происходит в 5-6 раз быстрее, но есть опасность потерять БД при внезапном выключении питания сервера.

    Поддерживает-ли Interbase поля типа autoincrement?

    В явном виде нет - вместо этого в InterBase существует другой механизм, называемый "генераторами". Генератор - некая переменная, значение которой может быть получено и увеличено на некоторое значение (дельту) при помощи встроенной функции GEN_ID. Создать генератор можно фразой
    CREATE GENERATOR MYGENERATOR;
    Обычно генераторы используют в триггерах, при этом текст триггера может быть следующим:
    CREATE TRIGGER TI_CLIENTS FOR CLIENTS
    ACTIVE BEFORE INSERT POSITION 0
    AS
    BEGIN
    IF (new.CLIENT_ID IS NULL) THEN
    CLIENT_ID = GEN_ID(MYGENERATOR, 1);
    END
    Вместо значения "1" может быть использовано любое число, на которое нужно иметь приращение текущего значения генератора. Механизм генераторов гарантирует что даже при конкурентном (параллельном) вызове функции GEN_ID каждому пользователю будет выдаваться уникальное значение. Последнее значение генератора всегда запоминается в БД, поэтому разработчику не нужно заботиться о "восстановлении" его максимального значения после подсоединения к БД. Генераторы являются переменными типа integer (longint), таким образом если предположить что новое значение возвращается в среднем с интервалом в 3 секунды, значений генератора хватит приблизительно на 270 лет.
    Примечание: если вы воспользуетесь приведенным выше примером использования генератора в триггере, то у вас может возникнуть следующая проблема - при добавлении записей с клиентского места новые записи будут "пропадать". Это связано с тем, что клиенту никаким образом не может быть передана информация об идентификаторе сформированом в триггере на сервере. Т.е. новую запись можно будет увидеть только либо перевыполнив запрос либо переместившись в конец таблицы (если еще не произошел fetch всех записей. Для исключения такой ситуации можно создать хранимую процедуру возвращающую значение генератора (так-же как и для триггера), и вызывать эту процедуру перед созданием новой записи (для Delphi - TTable.BeforePost).

    Как определить реальный размер поля типа BLOB, которое сохранено в таблице?

    Ниже приведена функция GetBlobSize, которая возвращает размер данного BLOB или MEMO поля. Пример вызова:
    function GetBlobSize(Field: TBlobField): Longint;
    var
    B : TBlobStream;
    begin
    B := TBlobStream.Create(Field, bmRead);
    try
    Result := B.Size;
    finally
    B.Free;
    end;
    end;
    procedure TForm1.Button1Click(Sender: TObject);
    begin
    { This sets the Edit1 edit box to display the size of }
    { a memo field named Notes. }
    Edit1.Text := IntToStr(GetBlobSize(Notes));
    end;
    Примечание: Этот способ не будет работать в методе OnCalcFields.

    Конвертация типов полей через COMPUTED BY.

    IB Database обладает интересной недокументированной возможностью. Обычно при объявлении вычисляемого поля COMPUTED BY придерживаются синтаксиса
    col_def = col { datatype | COMPUTED [BY] (< expr>) | domain} µµµ
    [DEFAULT { literal | NULL | USER}] µµµ
    [NOT NULL] [ ] µµµ
    [COLLATE collation]
    Как видите, синтаксис предлагает указать либо тип столбца (datatype), либо вычисляемое выражение (computed by). Указанием "или/или" является символ |. Обычно тип COMPUTED BY поля совпадает с исходным, на основе которого оно строится. Однако существует возможность явно определить конкретный тип столбца, даже не совпадающий с исходным. Можно проделать следующий эксперимент - создать таблицу с приведенной структурой:
    (определение PRIMARY KEY можно опустить, т.к. здесь оно введено лишь для удобства работы с такой таблицей из Database Explorer, т.к. BDE не позволяет обновлять таблицы, не имеющие первичного ключа)
    CREATE TABLE TESTCOMP(
    t_dataµFLOAT NOT NULL PRIMARY KEY,
    c_intµINTEGER computed by (t_data),
    c_numµNUMERIC(15, 2) computed by (t_data),
    c_charµCHAR(20) computed by (t_data))
    Теперь попробуйте ввести в эту таблицу записи со следующим значением T_DATA: 1.88, 3.2, 3.51. Вы увидите, что поле типа FLOAT сохраняет на диске не совсем те значения, которые вы вводили. Поле C_INT содержит округленное значение T_DATA. Поле C_NUM будет содержать либо точное значение T_DATA либо округленное, в зависимости от значения параметра псевдонима BDE ENABLE BCD = TRUE/FALSE. А вот C_CHAR будет содержать более точное значение вещественного числа C_DATA.
    При использовании этого трюка весьма полезным является просмотр значаний типа NUMERIC(15, 2) в строковом выражении. Дело в том, что вещественные числа не могут храниться с точностью целых, поэтому введенное 1.88 будет выглядеть в NUMERIC(15, 2) как 1.88, но на деле (в виде строки) окажется равным 1.8799999952316. Отсюда следует несколько выводов:
  • точность вещественных чисел ограничена, и число, хранимое как вещественное, никогда нельзя сравнивать на равенство (это общеизвестное правило);
  • точность полей типа FLOAT весьма низка (эквивалент дельфийского single), поэтому их можно использовать с большой осторожностью;
  • не все типы преобразуются из одного в другой - поле NUMERIC(15, 2) как INTEGER COMPUTED BY... будет содержать 0;
  • при обработке вещественных чисел (округление, агрегация, сравнение, сложение/вычитание и умножение/деление) нужно учитывать погрешность. Также известное бухгалтерское правило - при умножении и делении первым выполняется умножение;
  • не следует использовать вещественные типы в качестве первичных ключей таблиц - из-за погрешности или особенности обработки вещественных чисел процессорами клиента и сервера якобы одно и то-же число может оказаться разным, и запись по первичному ключу может оказаться "потерянной". Например запрос select * from testcomp where t_data = 1.88 может выдать пустой результат.
    (c) Epsylon Technologies

    Как правильно получить список таблиц, просмотров, функций и процедур в БД?

    Markus Kemper рекомендует следующие запросы:

    1. Для получения списка только пользовательских таблиц БД

    SELECT
    RDB$RELATION_NAME
    FROM
    RDB$RELATIONS
    WHERE
    ((RDB$SYSTEM_FLAG = 0) OR (RDB$SYSTEM_FLAG IS NULL)) AND
    (RDB$VIEW_SOURCE IS NULL)
    ORDER BY RDB$RELATION_NAME

    2. Для получения списка только системных таблиц БД

    SELECT
    RDB$RELATION_NAME
    FROM
    RDB$RELATIONS
    WHERE
    (RDB$SYSTEM_FLAG = 1) AND
    (RDB$VIEW_SOURCE IS NULL)
    ORDER BY RDB$RELATION_NAME

    3. Для получения списка просмотров

    SELECT
    RDB$VIEW_NAME
    FROM
    RDB$VIEW_RELATIONS
    ORDER BY RDB$VIEW_NAME

    4. Для получения списка функций

    SELECT
    RDB$FUNCTION_NAME
    FROM
    RDB$FUNCTIONS
    ORDER BY RDB$FUNCTION_NAME

    5. Для получения списка процедур

    SELECT
    RDB$PROCEDURE_NAME
    FROM
    RDB$PROCEDURES
    ORDER BY RDB$PROCEDURE_NAME

    Как ускорить выполнение множественных записей?

    Архитектура множественных поколений записи требует кооперативной сборки мусора. Это означает что каждый запрос который обнаружит неактуальные записи должен удалить их. Это позволяет значительно уменьшить блокировки и ускорить операции commit/rollback. Однако, как вы заметили, иногда выполнение запросов может сильно замедляться если на диске много устаревших записей. Это происходит из-за того, что изменения записываются как delta между старой и новой записью, и при чтении новой записи IB должен ее собрать из старых данных и delta. Для оптимизации сборки записей IB заполняет страницы данных только наполовину, оставляя вторую половину для хранения возможных delta. Если это пространство исчерпывается, то IB распределяет новые страницы для хранения delta. В этом случае ухудшается IO (для сборки записей приходится читать дополнительные страницы), которое и приводит к ухудшению общей производительности.
    Реально, большинство приложений не обновляют всю БД непрерывно, поэтому затраты на поколения записей оказываются несущественными в смысле общей производительности. (т.е. для хранения delta хватает свободного пространства на страницах данных, и не возникает лишнего обмена с диском). Другие SQL-серверы, которые не поддерживают множественные поколения записей, могут порождать проблемы другого рода - для запросов с изоляцией Repeatable Read либо полное дублирование данных, либо полное блокирование обновляемых таблиц.
    Кроме того, logging в других SQL-серверах может вызывать похожее ухудшение производительности.

    Как выбрать размер страницы БД?

    Этому посвящен один из разделов IB Data Definition Guide. Теоретически имеет смысл увеличить до 2К (с умолчательного 1К) размер страницы, если большее количество таблиц в вашей БД имеет количество записей > 200000 (200 тыс.). Hе забудьте, что увеличение размера страницы повлечет увеличение размера кэш-буфера IB, т.к. он измеряется в страницах. Безусловно, нужно ориентироваться на конкретную задачу - если ваше приложение часто выбирает случайные записи из БД, то производительность при увеличении размера страницы может ухудшиться (больше обмена с диском), и наоборот - для последовательных выборок больший размер страницы предпочтительнее.

    Как определить дисковое пространство, необходимое для хранения БД?

    Точно посчитать размер БД не представляется возможным. Однако для предсказания размера БД можно использовать определенные утверждения: При импорте данных страницы (data pages) заполняются наполовину. Таким образом объем импортированных данных будет в два раза больше (если данные импортируются из текстовых файлов). Размер ключа индекса в байтах равен 5 + длина поля. При импорте данных страницы индексов заполняются так-же как и страницы данных - наполовину. При восстановлении (restore) данных страницы данных будут заполнены опять-же наполовину, а страницы индексов - полностью. Hеобходимо учитывать, что при работе с БД возможно динамическое создание страниц, необходимых для хранения версий записей. Эти страницы не возвращаются файловой системе даже при операции database sweep. Как следствие этого, БД занимает минимально возможный объем только после операций backup/restore, и максимальный - при частом обновлении данных большим количеством пользователей. Кроме этого, IB упаковывает строки CHAR и VARCHAR, а также числовые последовательности, по алгоритму RLE.

    Можно-ли использовать имя таблицы как параметр хранимой процедуры?

    Как таблицу - нет, но можно передать какое-либо строковое или числовое значение, чтобы обработать его по IF .. ELSE. Хранимая процедура не может динамически получать имя таблицы. (похоже что причиной является то, что текст хранимой процедуры "скомпилирован" в BLR, который невозможно интерпретировать).

    Как оптимизировать запросы?

    Вот несколько простых рекомендаций для оптимизации запросов:
  • избегайте явного использования outer join;
  • используйте неявный join (select a,b, from a1, b1 where ...) вместо явного. При использовании явного join оптимизатор не работает;
  • пробуйте разный порядок таблицы в запросе для получения оптимальной производительности (также и для явного join);
  • пробуйте ваши запросы в WISQL, включив Show Query Plan и Show Statistics;
  • используйте индексы по полям, участвующим в условиях where;
  • не забывайте делать SET STATISTICS по индексам, созданным вами специально для ускорения запросов. Кроме того, возможно вам помогут документы, описывающих принцип работы оптимизатора IB. Их можно получить в ДемоЦентре. К сожалению, не существует точных правил по оптимизации запросов - это путь проб и ошибок, т.к. невозможно заранее предсказать ни ваши запросы, ни ваши реальные данные.
    Примечание: бывают ситуации, когда оптимизатор "настаивает" на использовании всех индексов по определенному столбцу, даже если создан специальный композитный индекс по всем полям where. В этом случае необходимо принудительно заставить оптимизатор IB использовать нужный запрос, причем скорость отработки такого запроса может ускориться в 10 раз.

    Можно-ли в запросах делать поиск по BLOB?

    Да. Однако в документации это не отражено. Поиск по строковым (CHAR, VARCHAR) полям или по BLOB можно производить при помощи операторов CONTAINING, STARTING WITH и LIKE. Hапример:

    SELECT * FROM MYTABLE WHERE BLOBFIELD CONTAINING 'sometext';

    Поиск по умолчанию считается case-insensitive (регистро-нечувствительный), поэтому для латинских букв строку поиска можно задавать строчными буквами (в нижнем регистре). В этом случае при поиске 'sometext' в ответ войдут записи с 'sometext', 'SOMETEXT' и 'SomeText'. К сожалению, для BLOB невозможно указать COLLATE для правильного перевода русских букв в верхний регистр, поэтому поиск будет производиться только по точному совпадению. При поиске подтип BLOB (SUB_TYPE 0 или 1 - текст или binary) не имеет значения.

    Есть-ли способ восстановить несохраненные (uncommitted) изменения БД, например в случае отключения питания?

    Hет. Такие изменения будут потеряны. Т.е. БД останется в состоянии, соответствующем последней подтвержденной (committed) транзакции. Hесохраненные данные в БД останутся в виде "осиротевших" страниц, которые можно очистить при помощи Server Manager, пункт меню Validate Database. Вполне возможно, что этот вопрос вызван тем, что восстановление состояния БД в IB отличается от других широкораспространенных SQL-серверов (Oracle, Informix, ...). IB не требует выполнения каких-то специфических действий для продолжения работы с БД в случае сбоя питания - изменения, происходящие до COMMIT, не записываются на место актуальных данных (т.е. отсутствует режим Dirty Read), поэтому они будут просто потеряны, а БД останется в рабочем состоянии.

    Я создал БД с правами пользователей в Local IB. После переноса этой БД на InterBase for NT все пользователи куда-то "пропали". В чем дело?

    Причина в том, что информация о пользователях InterBase хранится в специальном файле ISC4.GDB, и является общей для всех БД на конкретном компьютере. Очевидно что в вашем случае на сервере InterBase for NT отсутствовали пользователи, заведенные вами для Local InterBase. Вам придется создать всех ваших пользователей и для InterBase for NT (при помощи Server Manager).

    Что такое ISC4.GDB? Для чего нужна эта БД?

    База данных ISC4.GDB используется InterBase для хранения информации о пользователях (имена, пароли и т.п.). Удалять этот файл нельзя. Вы можете создать alias на эту БД и посмотреть ее содержимое, но самостоятельно (в ручную) не сможете создавать или изменять пользователей поскольку шифрация и дешифрация пароля выполняется InterBase.

    Можно-ли создать пользователя БД при помощи SQL-команды?

    Hет. Единственно правильный способ - использовать Server Manager. (Tasks | User Security), либо утилиту командной строки GSEC. Если иметь в виду добавление пользователей из клиенсткого приложения, то это возможно. Посмотрите пример IBUSERS.ZIP

    Почему таблица или Select показывается в Grid быстро, а перемещение в конец таблицы происходит долго?

    Когда вы открываете выборку, BDE производит Fetch только такого количества записей, которые помещаются в Grid. Если вы захотели переместиться в конец таблицы, то для большинства SQL-серверов возможно перемещение по записям только вперед - т.е. если вам потребуется поместить указатель в середину таблицы то BDE пришлось-бы заново перечитывать записи с ее начала. Причина такой работы в том, что SQL-серверы в большинстве возвращают результаты запросов в виде последовательных наборов записей. В навигационных БД напротив, возможно физическое позиционирование на любую запись таблицы. Если SQL-сервер поддерживает двунаправленные скроллируемые курсоры, то полное кэширование записей запроса выполняться BDE не будет.
    Кроме этого, TTable и TQuery работают по разному. TQuery при перемещении в конец таблицы действительно сделает выборку всех записей, т.к. он и не может иначе - для выполнения задано конкретное SQL-выражение. TTable-же напротив, показывает всю таблицу, и запросы для получения содержимого таблицы формируются автоматически. Поэтому TTable при нажатии вами в TDBGrid клавиш Ctrl-End сформирует запрос типа:
    SELECT * FROM TABLE ORDER BY INDEXFIELD DESC
    и покажет только видимые в DBGrid записи "с конца". Таким образом операцию перехода в конец таблицы TTable выполнит практически мгновенно. Пользователи Delphi 2.0 C/S могут сами убедиться в этом при помощи SQL Monitor.

    Как получить значение генератора?

    Dmitry Sergeev (Dmitry.Sergeev@f1851.n5020.z2.fidonet.org ) 18.12.1998
    Для получения текущего значения генератора следует обратится к таблице - владельцу генератора со следующим запросом:

    select
    gen_id(my_generator, 0)
    from
    RDB$DATABASE

    Как получить список пользователей Interbase?

    Ivanuts V.A. (ivanuts@altavista.net ) 5.12.1998
    a) Если необходимо получить список зарегестрированных пользователей на сервере InterBase, необходимо послать следующий запрос в базу данных ISC4.GDB (находится в дирректории InterBase):

    SELECT
    USER_NAME
    FROM
    USERS

    b) Если необходимо получить список зарегестрированных пользователей в конкретной БД, можно использовать следующий запрос в эту базу данных:

    SELECT DISTINCT
    RDB$USER
    FROM
    RDB$USER_PRIVILEGES

    Используя в этом запросе и другие поля таблицы RDB$USER_PRIVILEGES (без применения директивы DISTINCT) можно также получить данные о привилегиях зарегистрированных пользователей БД, назначенных на конкретные таблицы, просмотры, процедуры или их поля.


    Как программно сменить пароль входа на Interbase?


    Ivanuts V.A. (ivanuts@altavista.net ) 5.12.1998
    В своих разработках я применяю функцию Gregory H. Deatz из библиотеки FreeUDFLib. Я немного ее перестроил, но работой ее очень доволен. Если необходимо чтоб эта функция выполнялась на клиентском приложении, переменная SysUName должна иметь значение 'SYSDBA'.

    const
    UM_ERROR = 100001;
    UM_CANNOT_DETERMINE_ACTION = 100002;
    UM_CANNOT_SET_ENV_ISC_USERNAME = 100003;
    UM_CANNOT_SET_ENV_ISC_PASSWORD = 100004;
    UM_SYSUSER_NOT_VALID = 100005;
    UM_SYSPASSWORD_NOT_VALID = 100006;
    UM_CANNOT_EXECUTE_PROCESS = 100007;
    function UserProp(UserName, Password, SysUName, SysPword, Action: String): Integer;
    var
    Startup : TStartupInfo;
    Process : TProcessInformation;
    Status : DWORD;
    IB_BIN, szApp, szCmdLine : String;
    Env : Pointer;
    begin
    Result := UM_ERROR;
    Startup.lpReserved := PChar(0);
    Startup.lpDesktop := PChar(0);
    Startup.lpTitle := PChar(0);
    Startup.dwFlags := STARTF_USESHOWWINDOW;
    Startup.wShowWindow := SW_HIDE;
    Startup.cbReserved2 := 0;
    Startup.lpReserved2 := PByte(0);
    IB_BIN := GetIBPath +'\Bin';// GetIBPath - путь к дирректории InterBase
    szApp := IB_BIN + '\Gsec.exe';
    if Trim(Action) > '' then
    begin
    case Action[1] of
    'A': szCmdLine := szApp + ' -add ' + Trim(UserName) + '-pw ' + Trim(Password);
    'D': szCmdLine := szApp + ' -delete ' + Trim(UserName);
    'M': szCmdLine := szApp + ' -modify ' + Trim(UserName) + ' -pw ' + Trim(Password);
    else
    begin
    Result := UM_CANNOT_DETERMINE_ACTION;
    Exit;
    end;
    end;
    end
    else
    begin
    Result := UM_CANNOT_DETERMINE_ACTION;
    Exit;
    end;
    if ((Trim(SysUName) = 'SYSDBA') and (not SetEnvironmentVariable(PChar('ISC_USER'), PChar(Trim(SysUName))))) then
    begin
    Result := UM_CANNOT_SET_ENV_ISC_USERNAME;
    Exit;
    end
    else
    begin
    if (Trim(SysUName) <> 'SYSDBA') then
    begin
    Result := UM_SYSUSER_NOT_VALID;
    Exit;
    end;
    end;
    if ((Trim(SysPword) <> '') and (not SetEnvironmentVariable(PChar('ISC_PASSWORD'), PChar(Trim(SysPword))))) then
    begin
    Result := UM_CANNOT_SET_ENV_ISC_PASSWORD;
    Exit;
    end
    else
    begin
    if (Trim(SysPword) = '') then
    begin
    Result := UM_SYSPASSWORD_NOT_VALID;
    Exit;
    end;
    end;
    Env := GetEnvironmentStrings();
    if (CreateProcess(
    PChar(szApp), // lpApplicationName
    PChar(szCmdLine), // lpCommandLine
    PSecurityAttributes(0), // lpProcessAttributes
    PSecurityAttributes(0), // lpThreadAttributes
    False, // bInheritHandles
    HIGH_PRIORITY_CLASS, // dwCreationFlags
    Env, // lpEnvironment
    PChar(0), // lpCurrentDirectory
    Startup, // lpStartupInfo
    Process // lpProcessInformation
    )) then
    begin
    GetExitCodeProcess(Process.hProcess, Status);
    while Status = STILL_ACTIVE do
    begin
    Sleep(10);
    GetExitCodeProcess(Process.hProcess, Status);
    end;
    Result := Status;
    end;
    end;

    InterBase и использование Кирилицы.

    Да, InterBase прекрасно управляется как с кодировкой 866 так и с 1251. Да, как в Delphi 1.0, так и в Delphi 2.0, так и в Delphi 3.0. Для того, чтобы в БД в строковых полях использовались русские буквы, необходимо при создании БД указать в качестве дополнительного параметра фразу:

    DEFAULT CHARACTER SET WIN1251

    А в BDECFG32 в драйвере InterBase и его псевдонимах (aliases) указать языковый драйвер Pdox ANSI Cyrillic. Такие установки обеспечат нормальную работу с кодировкой 1251.
    Дополнительно, если Вы предполагаете использовать выражение UPPER в SQL-запросах, то Вам потребуется при создании таблиц InterBase использовать уточнение COLLATION SEQUENCE для строковых полей.
    К сожалению, установить COLLATE PXW_CYRL по умолчанию для базы данных невозможно (такой параметр отсутствует). Поэтому таблицы InterBase, созданные при помощи Database Desktop или компонента TTable не будут иметь правильного COLLATE для работы с функцией SQL UPPER. Эта проблема, необходимо отметить, не относится к работе с регистром русских букв внутри Delphi, поскольку для этого внутри VCL используются функции Windows, правильно переводящие буквы кодировки 1251 в верхний регистр и обратно. Hапример, если возможен запрос такого типа:

    SELECT * FROM CUSTOMERS
    WHERE
    UPPER(NAME) = 'ИВАHОВ'

    То таблицу CUSTOMERS придется создавать при помощи текста:

    CREATE TABLE CUSTOMERS
    (ID INTEGER NOT NULL,
    NAME CHAR(30) COLLATE PXW_CYRL,
    PRIMARY KEY (ID))

    Фраза COLLATE PXW_CYRL заставляет InterBase использовать таблицу трансляции символов PXW_CYRL вместо WIN1251, которая устанавливается по умолчанию для DEFAULT CHARACTER SET WIN1251. Однако можно использовать указание порядка сортировки "на ходу", без указания порядка сортировки в описании таблицы - при помощи того-же спецификатора COLLATE. В этом случае запросы могут выглядеть следующим образом:

    SELECT * FROM CUSTOMERS
    WHERE UPPER(NAME COLLATE PXW_CYRL) = 'ИВАHОВ'

    Учтите, что если Вы используете ORDER BY NAME, то порядок записей у полей с COLLATE PXW_CYRL будет отличаться от имеющих только CHARACTER SET WIN1251. В этом случае необходимо и в ORDER BY указывать COLLATE. Hапример:

    SELECT * FROM CUSTOMERS
    WHERE
    UPPER(NAME COLLATE PXW_CYRL) = 'ИВАHОВ'
    ORDER BY NAME COLLATE PXW_CYRL

    Примечание: при создании псевдонимов в Database Desktop языковый драйвер называется "ancyrr".
    Примечание: ODBC-драйвер InterBase фирмы Q+E, входящий в поставку Delphi 1.0, не может работать с кодировкой WIN1251, так как не имеет параметра SortOrder (как например ODBC-драйвер Access). В результате, при работе с этим драйвером через BDE русские буквы будут видны (благодаря LangDriver Pdox Ansi Cyrillic), но ввести их не удастся. Для приложений, работающих с ODBC напрямую, русские буквы будут видны как бессмысленный набор символов. В настоящее время ожидается новый 32-разрядный ODBC драйвер, в котором эти проблемы, мы надеемся, будут решены.
    Примечание: решить проблему с изменением данных в русской кодировке при использовании ODBC-драйвера можно следующим образом: напрямую указывать кодировку перед строковым значением, содержащим русские символы.
    INSERT INTO MYTABLE VALUES (1, _win1251 'Привет!')
    К сожалению, такой способ приводит к тому, что со стандартными компонентами TTable и TQuery можно работать только используя дополнительный компонент UpdateSQL (который позволяет переопределить запросы выдаваемые этими компонентами при INSERT, UPDATE, DELETE, и кроме этого присутствует только в 32-х разрядном Делфи)

    Получение значения поля типа Memo без использования объекта TDBMemo.

    1. Поместите, например, компонент Table1 на форму, выберите таблицу BIOLIFE.DB.
    2. Установите свойство Table1.Active в True.
    3. Поместите на форму компоненты Edit1 (для примера) и Button1.
    4. Добавьте код в обработчик OnClick для Button1:
    procedure Tform1.Button1Click(Sender : TObject);
    var
    Bs : TblobStream;
    P : array[0..50] of Char;
    begin
    FillChar(P, SizeOf(P), #0);
    Bs := TblobStream.Create(Table1.FieldByName('Notes'), bmRead);
    try
    Bs.Read(P, 50);
    finally
    Bs.Free;
    end;
    Edit1.Text := StrPas(P);
    end;

    Оглавление
    Назад